昨天的結果是兩顆都不完美:
如果問「哪一顆答得比較好」,這題我答不出來。它們各有一半。
而我卡了一陣子之後,意識到問題出在我問的方式。
我後來問的是:
哪一顆的缺點,我修得動?
這個問法一問出來,答案十秒鐘就出來了。
「不敢說事實不足」——那是指令的問題。我可以把那個出口寫得更明確、給它範例、甚至規定在某些條件下必須說。這是我控制得了的。
「最難那題答非所問」——那一題需要先確認某件事屬於既有行為,才推得出結論。而這一步,我可以在建置期就先算好,直接把結論當成一條事實餵給它。
它答不出來,是因為我要它當場推理——而那正是我 Day 17 說過不該做的事。
成本隨難度爆炸——1 條事實 1046 token,6 條事實 3918。而上線之後檢索一次會撈十條以上。
這條曲線我調不動。 不管我怎麼寫 prompt,它的思考量都跟著輸入的複雜度走。那不是一個可以用指令壓下去的東西,那是它工作方式本身。
所以準則就變得很清楚:
一個 prompt 能修的缺點,和一個架構性的缺點,不是同一個量級的東西。
前者是待辦事項。後者是天花板。
而我在挑的不是「今天誰表現好」,是「接下來幾個月,誰會擋住我」。
我不想給人一種「我看了一眼就放棄」的印象,所以這段要講清楚:我試了。
甲的思考是可以被關掉的——理論上。我試了三種方法:
第一,在指令裡叫它不要思考。 加上約定俗成的那個開關字串。沒有用。
第二,用命令列的參數關掉。 那個參數存在。沒有用。
第三,透過 API 明確傳一個「不要思考」的設定。 這是最正式的做法。還是沒有用。
三種都失敗。而當時我用的那個版本,就是關不掉。
這是這一段最值得記下來的部分。
當我用比較粗暴的方式去壓制它的思考時,輸出反而變髒了:
那段本來應該被藏起來的推理,開始漏進正式的答案裡。而且因為被中途截斷,還留下沒有配對完的標記——像是把一段內部獨白的開頭撕掉,結果剩下半個結尾掛在那裡。
換句話說:
我對抗它的結果,不是它不思考了,是它的思考跑到不該出現的地方。
而如果我不去對抗,讓它照自己的方式跑呢?
那個執行環境會很乾淨地把思考的部分分到一個獨立的欄位去,正式答案那邊反而是乾淨的。
我不動它,輸出比我動它還好。
我覺得這件事有一個更一般的意思:
當一個系統有它自己的設計意圖,而你硬要繞過去的時候,你通常不會贏。你只會得到一個更難處理的中間狀態。
這跟我後來對整個專案的態度是一致的——不要跟工具的本性打架,去找一個本性就適合的工具。
而它的兩個缺點,一個用 prompt 補,一個把工作搬回建置期。
兩個都在我的控制範圍內。
寫到這裡,我發現「缺點修不修得動」這句話,如果只停在選模型上,它會被浪費掉。
因為它其實在問一件更普遍的事:
你在評估的是「現在的表現」,還是「改善的可能性」?
這兩件事很容易被混為一談,而它們在時間軸上的行為完全不同。
表現是一個快照。 它告訴你今天的狀況,而今天很快就會過去。
而「修不修得動」是一個斜率。 它告訴你接下來會往哪裡走。
一個今天八十分、但每一個問題都改得動的東西,跟一個今天九十分、但那十分永遠拿不到的東西——半年之後,前者會遠遠超過後者。
我後來覺得,這條準則其實我一直在用,只是沒有把它講出來過。
評估一個工具的時候,真正該問的不是「它現在能不能做到我要的」,而是「它做不到的那部分,我有沒有辦法補」。一個功能少但可以擴充的工具,通常比一個功能多但封死的好。
評估一個流程的時候也一樣。一個有缺口但缺口看得見、補得上的流程,比一個看起來很完整、但問題全部藏在細節裡的流程安全。
而最難的是用在人身上。
一個人現在的能力是快照,而學不學得動、聽不聽得進去、願不願意改,那才是斜率。
我不想把這件事講得太輕鬆,因為判斷斜率遠比判斷快照難——快照你看得到,斜率你得等。
但至少我知道了一件事:當我拿「現在做得好不好」當唯一的判準時,我可能正在做一個很短視的決定。
選好了模型,那接下來就是把乙的缺點補起來——把 prompt 寫得更嚴格,讓它學會說「事實不足」。
聽起來很順。
而那是整個專案裡,我做過最失敗的一次嘗試。
明天那篇,是我把指令寫得更清楚,然後結果變得更糟的故事。
iThome鐵人賽
看影片追技術